Intermediate C 


Call the operator 
One of C’s biggest strengths is 
its excellent set of operators. 
An operator is simply a com- 
mand that can be built into an 
expression. In case you’ve 
never noticed, expressions are sort of a separate 
programming language that finds its way into 
nearly every other language. For example, when 
you write A+B*C this is a mini chunk of program 
which means multiply B by C and then add A. In 
languages that don’t support expressions — 
Assembler, for example - you really would have 
to write it out like that, and make it clear that the 
+ and * were commands to do something. Also 
notice that the order in which the commands are 
carried outisn’ta strict left-to-right reading of the 
expression. It’s this deviation from left-to-right- 
ness, and the way brackets can be used to group 
things together, that make expressions power- 
ful. Anyway, this is all general stuff — back to C. 
C started out close to the low-level machine 
architecture. Many of the commands in C are as 
they are because they can be efficiently translat- 


LACKS & Heaps 


=| 

No, I Saik 
Organise a 
Seminar on C 


ed into similar assembly language constructs. 
But expressions are one aspect of a high-level 
language that isn’t close to Assembler. It takes a 
lot of translating to convert an expression into its 
equivalent assembly language commands, 
though every high-level language has done it 
since Fortran. What can be close to the mach- 
ine’s structure is the operators. For example, all 
languages (exceptions on a postcard please) im- 
plement the arithmetic operators +, -, * and /. 
How close these are to the hardware depends on 
whether the machine has an arithmetic unit that 
can perform such operations. Where C differs is 
in the provision of some specialised operators 
that appear at first sight to be quite unnecessary. 


Ups and downs 

For example, the + + or ‘increment’ operator just 
adds one to the variable to which it’s applied. 
That is, + +b is the same as b=b+1. Why have 
an increment operator? Simply because most 
machines have an inc instruction which will add 
1 to aregister very quickly. You could argue that 
a good optimising compiler should pick up the 
b=b+1 and use inc, and indeed this is how many 
high-level languages deal with it, but C takes the 
operation even closer to the hardware. 
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In the PDP-11 architecture — and remember 
C was designed as a system language for this 
machine — addressing registers can be ‘pre’ or 
‘post-incremented’. What this means is that you 
could either give a command that incremented 
the register before it was used within the instruc- 
tion or one that incremented it after it was used. 
Nearly every PDP programmer will tell you this 
was useful, so it’s been incorporated into C. Ifyou 
write + +a, the variable will be pre-incremented; 
its value will increase before it’s used. Ifyou write 
a+ +, it will be post-incremented; its value will be 
incremented after it’s used. Now ask yourself 
what values are in x and y after: 


y=10; 
x=+4+ye 


The answer is 11 in both. Now what about: 


y=10; 
x=y++2 


In this case there’s 10 in x and 11 in y, because y 
is incremented after its value has been used. 
(There’s no real difference between ++i and 
i++ used in isolation — they both add one to i.) 

Notice that the increment operators break 
the rules of a pure expression, in that their only 
action is to cause a side-effect to the evaluation of 
the expression. It’s a rule of simplicity that noth- 
ing should change as the result of the evaluation 
of an expression except the variable to which 
you're assigning the result. Clearly, a=++band 
a=b++ don’t obey this rule, as both a and b 
change their value. This is dangerous, because 
in acomplex expression you might miss the fact 
thata variable embedded deep within the expres- 
sion has changed. Of course, there’s the school 
of thought that says you should never write a 
complex expression anyway! 
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The worst part about such expression side- 
effects is that they can be buried inside another 
command. For example: 


printf(d%,a+ +); 


not only prints the current value of a, it also adds 
1 to it. This means the value of any variable can 
be changed within statements you wouldn’t 
expect to change values. If you don’t think this is 
an odd idea, you’ve been programming in C too 
long — other languages just don’t allow it! 

So now you know why there’s an increment 
operator and why it comes in both pre and post 
forms. Of course, there’s a—— decrement opera- 
tor that can be used in pre and post forms too. 


Hot topic 


XMS memory 
This month I’m going to devote 
alarge chunk of Stacks & Heaps 
to asingle topic: XMS memory. 
Why? Well, the other day I 
found myself writing: “Expand- 
ed memory is an old and confusing standard, and 
the sooner it dies out the better.” Harsh words, 
but true. The only advantage of expanded mem- 
ory is that it works on almost any PC. Old XTs 
have to have special hardware fitted; some 286s 
can manage without; and all 386s can produce 
expanded memory without the extra hardware. 
What's been puzzling me is that even today the 
great majority of programs that need extra mem- 
ory still demand expanded, even though there’s 
been a similar standard for using extended mem- 
ory, ie XMS, for some time now. In practice, XMS 
memory is easier to use — and it doesn’t need the 
pesky 64K page frame that clogs upper memory. 
To see if I can encourage you to make use of 
XMS memory on an equal footing with EMS, 
please read on. Even if you don’t follow the pro- 
gramming details, you might like to know what 
that Himem.sys driver in Config.sys is doing! 


Standard form 

The original XMS specification wasn’t much to 
write home about; it was really only concerned 
with access to and management of the ‘high 
memory area’, or HMA toits friends. The current 
version is also concerned with the HMA, and in 
addition deals with the management of ‘upper 
memory blocks’ (UMBs). Both the HMA and 
UMBsare of less interest in our present context, 
because they can be reached from Real mode and 
so look like conventional memory. Besides, the 
HMA and available UMBs are usually used up by 
system code, leaving none left over for applica- 
tions. Still, it’s worth looking more closely at the 
HMA/UMBs part of XMS, if only to make sure 
there’s nothing nasty lurking under that rock. 
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Himem.sys functions 


Code Function 


General 
Oh) — Get XMS version number 
Something to let you check the driver version 


HMA | 
Th) _ Request high memory area 
2h) __ Release high memory area 
Notice that you can either have or not have 
the HMA —it’s never cut up into blocks 


A20 management 

3h) — Global enable A20 

4h) — Global disable A20 

5h) Local enable A20 

6h) Local disable A20 

7h) ~~ Query A20 
You have to enable the A20 line before 
requesting or using the HMA 


Extended memory management 

8h) — Query free extended memory 

Qh) _ Allocate extended memory block 

Ah) _ Free extended memory block 

Bh) — Move extended memory block 

Ch) — Lock extended memory block 

Dh) — Unlock extended memory block 

Eh) — Gethandle information 

Fh) — Reallocate extended memory block 
Notice that these functions include moving 
blocks of XMS memory, and this can be 
from/to conventional memory 


UMB management 
10h) Request upper memory block 
11h) Release upper memory block 
Once you have a UMB, it’s up to you to use it 
— after all, it’s just like conventional memory 


In case you're a little rusty on this, the HMA 
is the first 64K (minus 16 bytes) above 1Mb. The 
amazing thing about the HMA is thatit’s achunk 
of extended memory that can be reached in Real 
mode, because Intel forgot to turn off all the ad- 
dressing lines while the 8088 was in Real mode. 
In Real mode, addresses are formed by adding a 
segment address to an offset. The segment 
address can be set almost to the top of the 1Mb of 
Real-mode memory, ie to FFFFO, and you can 
still add an offset in the range 0 to FFFF. This of 
course needs more than the 20 addressing lines 
(A0-A19) required to work with 1Mb, but remem- 
ber Intel hadn’t switched the addressing lines off, 
so the 21st line, A20, responded — and lo, you 
could address the first 64K above 1Mb. 

Now, the only complication to all this is that 
before the value of the trick was discovered, the 
hardware designers had designed it out! They 
placed a gate, under the supervision of the key- 
board controller, to block the A20 address line 
and so make the 286 and the 386 in Real mode 
behave exactly like an 8088/86. Fortunately the 
gate can be turned on and off, so access to the 
HMA is possible. The bad news is that different 
PC manufacturers used slightly different gating 


hardware. Evening out these differences was the 
first task for the XMS specification, and the early 
Himem.sys drivers were really nothing more 
than consistent ways of gating the A20 line. The 
latest versions also make sure two programs 
don’t attempt to use the HMA at the same time. 

The first version of Himem.sys was used to 
allow Windows 2 to gain access to the HMA, and 
the development of XMS has been influenced by 
the needs of Windows ever since. The latest stan- 
dard includes the management of the ‘upper 
memory area’ (UMA) and extended memory in 
general. The UMA, the area between 640K and 
1Mb, was needed to allow MSDos 5 to move dri- 
vers and TSRs out of the 640K of conventional 
memory. XMS manages the fragmented free 
blocks of UMA in such a way that two programs 
can’t attempt to use the same block. In the same 
way, it manages the general free pool of extend- 
ed memory and will respond to requests to allo- 
cate and de-allocate XMS memory blocks. 


Inside information 

There — now you know what Himem.sys, Micro- 
soft’s XMA driver, is for. But to get closer to it, 
you need to know the functions it supports. 
These fall into five groups: general; HMA; A20, 
extended and UMB management. Each function 
corresponds to a code — see the table. 

Nowwe have to look at exactly how to call the 
XMS driver, ie Himem.sys. This is a two-stage 
process: first use the multiplex interrupt to find 
the location of the driver, then you can call it like 
any other subroutine. But first, is it installed? To 
answer this question you have to execute Int 2Fh 
with ax set to 4300h. If there is an XMS driver 
installed, 80h will be returned in al. That is: 


mov ax,4300h.! 
int 2Fho 

cmp al,80hW 
jne NoDriver. 


Ifan XMS driver is installed, you can discover its 
location by performing Int 2Fh with ax set to 
4310h. The address is returned in es:bx. 


mov ax,4310h_ 

int 2Fho 

mov word ptr xms, bx.! 
mov word ptr xms+2,es 


where xms is a double word. 

Once you have the address of the driver in 
xms, you can call it to perform a function by load- 
ing the function code in ah. The result of the call 
will usually be returned in dx with a status code 
in ax (0001h for success and 0000 for failure). If 
the call fails, an error code will be returned in bl. 

Other registers are used in some of the XMS 
functions. For example, to discover the XMS ver- 
sion number you would use: 


mov ah,00h 
call xmst 


with the result in dx. 


C for yourself 


As an illustration of how XMS memory can be 
used from an ordinary Dos program, I started 
work on something simple in C. There’s an XMS 
library you can get from Microsoft that imple- 
ments XMS calls as standard C functions, but I 
thought it would be more interesting to do the job 
without. I decided to use Borland C with its inline 
assembler BASM, but after trying and — not for 
the first time — failing to make it work, I gave up 
and used TASM. Fortunately you can still use it 
inline — all you have to do to change from BASM 
is to tick the Compile Via Assembler box. 

OK, by using TASM I’ve narrowed down the 
number ofreaders who can use this example, but 
that wasn’t my original intention. If anyone can 
tell me how to get the bugs out of BASM, let me 
know. Incidentally, even if you’re not interested 
in XMS memory, the next bits should give you 
some good ideas about using inline Assembler. 

The nice thing about inline Assembler is that 
you don’t have to fuss with passing parameters or 
housekeeping in general. Your assembly lan- 
guage instructions are simply placed in the 
assembly language generated by the compiler 
~ exactly where you write them. The easiest way of 
showing you how this worksis to, er, showyou... 

The first C function I had to write was one to 
check that the driver was installed: 


int xms_in(void) 
{ 
int res; 
asm {1 

mov ax,4300H.1 

int 2fHW 

mov res,ax._ 

}4 
res=res & OxO0FF; 
return (res); 


}4 


Notice the way the result of the testis returned in 
the integer variable res in the usual C fashion. See 
what I mean about not having to worry about 
assembly language calling methods? The func- 
tion returns 0x80 if the driver is installed, and 
can be used quite happily in statements like: 


if (xms_in()!=0x80) return (0); 


The next easy function to write discovers the 
location of the XMS driver: 


void init_xms(void) 
{i 
asm{ 


xms dd 0. 
mov ax,4310H 
int 2fHO 
mov word ptr xms,bx 
mov word ptr xms +2,es. 
}4 

bt 


There are a couple of interesting things about 
this routine. Firstly, it declares some storage in 
the assembler part —ie xms is a double-word (32- 
bit) location. Secondly, it doesn’t need to return 
any result because xms is global to all the inline 
assembly language in the module. (This fact was 
discovered by reading the assembler’s output!) 


How much is that memory? 

Now that we have the location of the driver, the 
sky’s the limit—we can call it to perform any XMS 
function. It pays to start modestly, though, and 
the first XMS function worth implementing is to 
discover how much free XMS memory there is: 


unsigned intxms_free(void) 
{unsigned int total; 
asm 
{i 
mov ah,8.1 
call xms. 
mov total,dxt 
}4 
return (total); 
}4 


Now we have aaset of functions that make it pos- 
sible to try a little bit of a main program: 


int main(void).J 

{4 ~ 

unsigned int amount 

a 

if (xms_in()!=0x80) return (0); 
init_xms();J 

amount=xms_free(); 

printf("\n\n KBytes free= %d \n",amount);1 
}4 


which simply tells you how much XMS memory 
is available. 


Mine, all mine 

The next obvious step is to grab some of the free 
XMS memory for our own use. This is relatively 
easy: 


unsigned intxms_alloc(unsigned int size) 
{4 
unsigned int handle; 
asm.t 
{i 
mov dx,size! 
mov ah,9.1 
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call xms. 
mov handle,dx. 
}4 
return (handle); 
}o 


The parameter size sets the size of the block in K. 
Butwhat’sall this about handle? Well, XMS mem- 
ory is controlled and accessed by handles, just as 
files are. The allocation function returns a handle 
to the allocated memory, and this has to be kept 
safe because you need to present it again if you 
want to do anything with the block. For example, 
to de-allocate the block you’ve just grabbed you'd 
need the following function: 


unsigned intxms_unalloc(unsigned int handle) 
{unsigned int result; 
asm.t 
{a 
mov dx,handle. 
mov ah,OAH. 
call xmst 
mov result,ax_ 
}o 
return (result); 


}4 


Notice that this time I haven’t been quite so lazy, 
and have returned the status code. If you don’t 
return an XMS block back to the free pool before 
the program ends, it vanishes for ever — at least, 
until you start the machine again. 

To try this pair out, you need to add the lines: 


handle=xms_alloc(16);W 

printf("Handle = %X \n" handle); 
amount=xms_free(); 

printf("%d KBytes free after allocation \n",amount);_1 

a 

result=xms_unalloc(handle); 
amount=xms_free();. 

printf("%d KBytes free after unallocation \n",amount); 


tothe main program listed earlier. Notice that the 
first instruction allocates a modest 16K block, 
but on my system this could have been as large 
as a couple of megabytes. As long as everything 
is working, you should see the amount of free 
XMS go down and then back up by the amount 
you've allocated and then de-allocated. 

Handles are in short supply in most situa- 
tions. You can set the Himem.sys driver to sup- 
ply more, but it’s better to be sparing with them. 


Theory and practice 

Fine, now we can allocate and unallocate 
megabytes of XMS memory — but how do we get 
to use it? There are two distinct ways. Youcan use 
the calls ‘Lock’ and ‘Unlock XMS’. Lock returns 
a full 32-bit linear address of the XMS block and 
promises not to move it again until you unlock it. » 
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The trouble with a 32-bit linear address is that 
you can’t use it unless you switch to Protected 
mode. If you're writing a Protected mode pro- 
gram, this is how you gain access to your block of 
XMS memory. But what if you’re writing a Real 
mode Dos program? — and this is what you’re 
likely to be doing if you are considering XMS as 
an alternative to EMS. There’s a little-known 
Bios interrupt that will move data between 
extended and conventional memory, but person- 
ally I wouldn’t touch it with an online debugger! 
The solution is to use the XMS function 
‘Move extended memory block’. When you call 
this function, you just have to set ah to OBh and 
ds:si to point to a parameter block of the form: 


Length dd ?; 
SourceHandle dw?; 
SourceOffset dd ?; 
DestHandle dw?; 
DestOffset dd ?; 


Number of bytes to transfer 
Handle of source block 
Offset into source block 
Handle of destination block 
Offset into destination block 


This can be used to move the contents of one 
XMS block into another, given only their handles 
— but how does this help with transfer to and from 
conventional memory? Well, if you use a zero 
handle, it’s assumed that the offset is a standard 
segment:offset address of the start of a block in 
conventional memory. 

Now all the pieces are in place, and it’s time 
to implement a C function to do the job. But 
rather than use a boring assembly language 
block, let’s use a C struct instead: 


struct XMM_Move { 


unsigned long Length; 
unsigned short SourceHandle; 
unsigned long SourceOffset; 
unsigned short DestHandle; 


unsigned long DestOffset; }; 


The move function is now relatively easy: 


unsigned int xms_move(unsigned long len, _! 
unsigned short shan, 
unsigned long soff, 
unsigned short dhan, 
unsigned long doff ). 
ay 
{ unsigned int result; 
XMM_Move Block;. 
pel 
Block.Length=len; 
Block.SourceHandle=shan;. 
Block.SourceOffset=soff;! 
Block.DestHandle=dhan; 
Block.DestOffset=doff; 
a 
result=(int) &Block; 
-! 
asm {1 
mov si, result. 
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This little message might look innocent, but we know where it’s been, don’t we? 


mov ah,ObH. 
call xms 
mov result,ax. 
}o 
return (result); 
}4 


However, there are still a couple of tricky bits that 
you have to discover how to do by reading the 
assembly language output. The line: 


result=(int) &Block 


is a bit weird in that it typecasts a near pointer 
&Block into an integer. This is the only reliable 
way of getting the offset of the struct into the si 
register — no matter what the manual says! 
Notice that there’s no need to load ds, because 
it’s already pointing to the correct data segment 
as part of the rules of C compilation. 

You have to pass this function the pointers 
that have been converted to the long ints. One 
way of doing this is (where ais an array and prta 
far pointer to char): 


prt=(char far *) a; 
result=xms_move(40,0,(long int) prt,handle,0);_ 


The first line typecasts a, which is already a point- 
er toafar pointer. The typecastin the middle then 


converts it to a long int —just to show it all works! 


Testing, testing 

Nowcomes the time to testitall. Areasonable but 
unspectacular test is to move the contents of an 
array up into XMS memory and then down again 
into another array. If you change the definitions 
at the start of our evolving main program to: 


unsigned int amount,result,handle;— 

char far *prt;_! 

char a[50]="Computer Shopper uses XMS memory", b[50] 
tol 


you not only have the ints you need and the far 
pointer, but two test arrays. If you also insert: 


printf("Source string = %s \n",a);— 
prt=(char far *) a; 


result=xms_move(40,0, 
(long int) prt,handle,0); 
printf("result=%d \n", 
result); 

is 

prt=(char far *) b; 
result=xms_move(40, 
handle,0,0,(long int) prt); 
printf("Destination string = 
%S \n",b);1 
printf("result=%d \n", 
result); 


between the allocation of the XMS block and its 
de-allocation, you should see the message 
‘Computer Shopper uses XMS memory’ printed 
twice. Notvery exciting, but we know the text has 
been shot up into XMS memory and back again. 

While I was trying to make this program 
work — yes, that’s right, my programs don’t work 
first time either — I made a few simple mistakes 
thatyou may be able to learn from. The first point 
is that the length of the transferred block has to 
be even — it says so in the small print of the XMS 
spec, but I didn’t notice it at first. 

The second mistake was really elementary: 
don’t forget to copy enough of the source string 
to include its terminating zero in the case of both 
moves. If you lose the terminating zero, you'll 
just see garbage printed until a zero is hit by acci- 
dent. Not a serious error, but when I saw the 
garbage I naturally assumed there was some- 
thing mangling the XMS memory, and went on 
an exotic bug-hunt! Sometimes checking out the 
simplest possibilities first is a worthwhile exer- 
cise... 


Knowledge is power 

Now that you can move a chunk of conventional 
memory into XMS and back again both ways, 
there should be no more excuses for using only 
expanded memory. If you're really planning to 
build XMS into a program, I would advise using 
the Microsoft XMS library — it’s neater and it’s 
complete. 

No matter what you use, the next step from 
here is to work out how best to manage the mem- 
ory that you have available to you to store your 
program’s data. Notice that you can move parts 
of XMS blocks into conventional memory and 
vice versa by using the offset and length parame- 
ters creatively. There’s also a re-allocate com- 
mand if you want to make an XMS block bigger 
or smaller, 

All in all, XMS is much more sophisticated 
than EMS fixed-size/fixed-location blocks. Even 
so, if you really want to you can use the same 
memory management strategies you use with 
EMS, so that you can easily support both forms 
of memory. 

Next month, something a little simpler, I 
promise! 


